Как вы знаете, совсем недавно была выпущена новая версия продукта StarWind Virtual SAN, предназначенного для создания отказоустойчивых хранилищ на базе iSCSI для виртуальных машин VMware vSphere и Microsoft Hyper-V. О новых возможностях этого продукта мы уже рассказывали тут, кроме того, скоро мы расскажем о нововведениях более детально.

Некоторое время назад мы уже писали об изданиях решения StarWind (и тут), но сейчас продукт существенно поменялся - появились новые возможности и улучшения, которые мы просуммировали в таблице ниже:

Возможности продукта	StarWind iSCSI SAN Free Edition (бесплатно)	StarWind Virtual SAN для VMware и Hyper-V	Комментарий
Емкость хранилищ	Для одного узла - не ограничено, для HA-конфигурации - 128 ГБ	Зависит от типа лицензии - от 1 до 512 ТБ	Можно купить лицензию на 1 ТБ и расширять ее апгрейдами
Размер допустимого к использованию кэша	512 МБ	Не ограничено	Для коммерческой лицензии можно использовать всю память сервера под кэш
Централизованное управление	StarWind Management Console		Консоль бесплатного и коммерческого издания - одна. Апгрейд происходит с помощью ключа.
Число серверов на лицензию	2	2 или 3	Для коммерческой лицензии можно использовать 3 узла при соблюдении лицензированной емкости. Подробнее тут.
Число одновременных соединений по iSCSI	Не ограничено		Обе версии позволяют неограниченное число клиентов.
Число лицензированных портов Ethernet	Не ограничено		Любые порты можно как угодно агрегировать и использовать.
Число дисков хоста	Не ограничено		Диски можно использовать в любой конфигурации.
Техническая поддержка	Ограничена (только веб-форум)	Полная поддержка (уровень Standard или Premium)	Уровень Standard - время реакции 4-12 часов (почта, телефон), можно сделать апгрейд на премиум-поддержку.
Отказоустойчивость узлов типа Active-Active			Поддержка прозрачной для виртуальных машин отказоустойчивой конфигурации (как Failover, так и Failback). Для бесплатной версии - только для 128 ГБ.
Асинхронная WAN-репликация			Возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ. Теперь также возможна репликация даже на очень медленных каналах
Использование ресурсов NAS/SAN			Поддержка в качестве хранилищ как NAS, так и SAN-ресурсов. Утилита NAS Configurator - помогает сделать экспорт NFS/SMB-шары для использования в кластерах StarWind High Availability или MS Cluster.
Технология Disk bridge			Технология эмуляции SCSI-слоя, что позволяет использовать любые типы хранилищ (PATA/SATA/RAID).
Техника SPTI			Техника, позволяющая соединять физические устройства с удаленными машинами.
Хранение данных в виде файла образа (Image File)			Хранение виртуальных дисков машин в виде файла.
Поддержка технологии CDP и снапшотов			Более подробно - тут.
Возможности Thin Provisioning (растущие по мере наполнения диски)			Аллоцируется только необходимое для записей данных пространство диска.
Технология High speed caching			Использование памяти для защищенного и высокопроизводительного кэширования.
Сервисы мониторинга и нотификаций администраторов			Единая консоль мониторинга происходящих с хранилищами событий и средство оповещения администраторов по email или SNMP.
Дедупликация данных (собственный высокопроизводительный механизм)			Inline-дедупликация StarWind не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.

Из таблицы видно, что бесплатная версия StarWind Virtual SAN Free мало чем отличается от платной, кроме ограничения на размер отказоустойчивого хранилища в 128 ГБ. Поэтому если у вас есть необходимость в создании кластеров хранилищ на базе локальных дисков серверов - StarWind на сегодняшний день является единственным на сегодняшний день продуктом, позволяющим сделать это бесплатно.

Скачать пробную или бесплатную версию StarWind Virtual SAN для VMware или Hyper-V можно по этой ссылке.

На проходящей сейчас конференции TechEd 2014 в Хьюстоне компания Microsoft сделала несколько интересных анонсов, касающихся публичного облака Microsoft Azure. Мы уже писали о выпуске превью-версии Azure RemoteApp, а ниже расскажем о других нововведениях Azure.

Во-первых, прояснилась ситуация с Microsoft Azure Site Recovery (так теперь называется решение Hyper-V Recovery Manager) - он будет доступен в виде превью в июне этого года. Это катастрофоустойчивое решение позволяет проводить прямое и обратное восстановление виртуальной инфраструктуры датацентров, находящихся под управлением Microsoft System Center 2012. При этом будет доступна возможность восстановления онпремизной инфраструктуры под управлением SC Virtual Machine Manager в публичное облако Microsoft Azure.

Процесс восстановления будет полностью оркестрируем на основе заданного сценария, в качестве интервала репликации можно будет использовать время 30 секунд, а также 5 или 15 минут. Можно будет иметь до 15 точек восстановления, консистентность будет обеспечиваться технологией VSS, а пользователь при необходимости сможет включать шифрование данных.

Плата за Microsoft Azure Site Recovery будет производиться на основе используемого инфраструктурой хранилища, так как в нормальном режиме репликации виртуальные машины на резервной площадке будут выключены. Если в качестве резервной площадки используется облако Azure, то виртуальные машины там будут приведены к стандартным инстансам - small, large, A6, A8, в зависимости от такого, какой ближе по конфигурации.

Также будут поддерживаться диски VHDX, но ВМ второго поколения (Generation 2 virtual machines) пока не поддерживаются. Более подробно о решении Microsoft Azure Site Recovery можно почитать тут.

Во-вторых, было анонсировано расширение Microsoft Azure Antimalware, предоставляющее сервисы защиты от вредоносного ПО в виртуальных машинах на платформе Azure.

Теперь в ВМ можно использовать расширения от различных вендоров, обеспечивающие ее защиту от вирусов и т.п.:

В-третьих, Microsoft анонсировала доступность решения Microsoft Azure ExpressRoute, которое представляет собой единое решение для организации межоблачных VPN, безопасных соединений VNET-to-VNET, управление выделенными IP, внутреннюю балансировку и интеграцию с такими провайдерами, как AT&T, Equinix, Verizon, BT и Level3.

Технические подробности о ExpressRoute доступны тут.

Также на TechEd было сделано еще несколько анонсов, касающихся облака Azure, таких как сервис импорта-экспорта виртуальных машин на дисках для больших объемов данных, новая служба SMB File Sharing Service и т.п. Обо всем этом можно почитать тут.

Как многие уже слышали, совсем недавно вышла первая версия продукта VMware VSAN, который был выпущен одновременно с релизом обновленной платформы VMware vSphere 5.5 Update 1. Многие уже принялись тестировать это решение, которое (что похвально) теперь работает производительнее своей же бета-версии и в то же время линейно масштабируется по количеству узлов ESXi с точки зрения производительности...

Достаточно давно мы писали о технологии VMware vFlash (теперь она называется vSphere Flash Read Cache), которая пришла на смену технологии Swap-to-SSD - она позволяет использовать локальные SSD-диски хостов VMware ESXi для задач кэширования. Напомним, что Flash Read Cache позволяет использовать кэширование данных только на чтение для дисков VMDK виртуальных машин, работает она на уровне гипервизора и существенно улучшает производительность виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций на чтение.

Очевидно, что SSD-кэш, который по производительности находится между оперативной памятью и обычными дисками, существенно повышает быстродействие в системах, где периодически наблюдается недостаток ресурсов RAM. Все это дело работает в кластере до 32 хостов ESXi.

Однако, иногда вам может понадобиться вернуть SSD-накопитель хосту ESXi, чтобы использовать его для других задач. Можно попробовать отключить использование ресурсов vFlash для всех виртуальных машин хоста, затем пойти в раздел "Virtual Flash Resource Management" и выбрать опцию "Remove All" - но это не сработает. Появятся следующие ошибки:

Host’s virtual flash resource is inaccessible.
The object or item referred to could not be found.

Чтобы вернуть диск SSD снова в строй понадобится удалить специальный раздел - vFlash File System partition. Для этого нужно сначала его найти. Выполняем команду:

ls /vmfs/devices/disks

Тут мы видим нашу SSD-партицию (видим в середине буквы "SSD" - не ошибитесь - нам нужен раздел без ":1"):

disk ID “t10.ATA_____M42DCT032M4SSD3__________________________00000000121903600F1F”

Сносим эту партицию с помощью утилиты partedutil, используя найденный Disk ID:

partedutil delete "/vmfs/devices/disks/t10.ATA_____M42DCT032M4SSD3__________________________00000000121903600F1F" 1

Что-то вроде этого:

После чего мы видим, что диск SSD освободился и его можно использовать на хосте VMware ESXi:

Источник.

На днях компания StarWind Software выпустила долгожданный Release Candidate своей новой версии решения для создания отказоустойчивых хранилищ под виртуализацию - StarWind SAN V8 RC. Напомним, что несколько ранее вышла третья бета-версия данного продукта. Ну а в текущей версии появилось еще несколько новых возможностей, которых не было в предыдущих бетах.

Итак, окончательно определился список новых возможностей StarWind V8, которые мы увидим в финальном релизе продукта:

• L2 Flash Cache - кэш уровня L2, который работает непосредственно с кэшем уровня L1 в RAM, что существенно улучшает производительность.
• Файловая система LSFS, которая изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего). Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
• Inline-дедупликация StarWind, которая не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.
• Улучшенный интерфейс мастеров развертывания хранилищ для Windows Server 2012 с поддержкой скриптов PowerShell.
• Возможность интеграции с механизмом SMI-S для Windows Server 2012 R2.
• Massive Scale-Out storage architecture - возможность масштабирования узлов кластера хранилищ до любого числа (а не только 3 как сейчас).
• Asynchronous WAN-replication - возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ. Теперь также возможна репликация даже на очень медленных каналах.
• Поддержка примитивов VAAI для устройств на одном узле и устройств с синхронной репликацией: поддерживаются команды WRITE SAME, EXTENDED COPY, ATS.
• Репликация конфигурации узла, включая информацию о снапшотах, что позволяет в случае сбоя сохранить созданную оригинальную конфигурацию и реплицировать ее уже, например, на третий узел.
• VSS-провайдеры для поддержки устройств с LSFS - появились Hardware VSS provider (для устройств с синхронной/асинхронной репликацией) и Software VSS Provider (только для обычных LSFS-устройств).
• Утилита NAS Configurator - помогает сделать экспорт NFS/SMB-шары для использования в кластерах StarWind High Availability или MS Cluster.
• Утилита VSA Builder - позволяет развернуть готовую виртуальную машину StarWind VSA на серверах VMware ESXi.
• V2V Converter в StarWind Management console - теперь прямо из консоли можно конвертировать файлы дисков виртуальных машин из формата VMDK в VHD и обратно, а также из/в нативный формат IMG StarWind.

Release notes по продукту StarWind SAN V8 доступны здесь. Скачать релиз-кандидат можно по этой ссылке. До финальной версии осталось совсем чуть-чуть.

Не так давно мы писали о том, что обновилась бета-версия решения StarWind SAN V8 (это было сделано неофициально), предназначенного для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин. На днях же была выпущена обновленная официальная версия - StarWind SAN V8 Beta 3.

Напомним сначала основные новые возможности StarWind V8:

• L2 Flash Cache - кэш уровня L2, который работает непосредственно с кэшем уровня L1 в RAM, что существенно улучшает производительность.
• Файловая система LSFS, которая изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего). Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
• Inline-дедупликация StarWind, которая не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.
• Simplified and improved GUI - улучшенный интерфейс мастеров развертывания хранилищ для Windows Server 2012 с поддержкой скриптов PowerShell.
• Возможность интеграции с механизмом SMI-S для Windows Server 2012 R2.
• Massive Scale-Out storage architecture - возможность масштабирования узлов кластера хранилищ до любого числа (а не только 3 как сейчас).
• Asynchronous WAN-replication - возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ.
• Поддержка примитивов VAAI для устройств на одном узле и устройств с синхронной репликацией: поддерживаются команды WRITE SAME, EXTENDED COPY, ATS.
• Репликация конфигурации узла, включая информацию о снапшотах, что позволяет в случае сбоя сохранить созданную оригинальную конфигурацию и реплицировать ее уже, например, на третий узел.

А вот какие улучшения появились в предрелизной версии StarWind SAN V8 Beta 3 (по сравнению с прошлой "неофициальной" бета-версией):

Улучшения устройств LSFS

• Обработка размера устройства и его заполненности напрямую от нижележащего физического устройства.
• Исправлен баг, приводивший к ошибкам записи на диск

Синхронная репликация устройств LSFS

• Пофикшены ошибки при работе со снапшотами (удаление и создание).
• Поправлена ошибка, когда один из HA-узлов почему-то выпадал в состояние "unsynchronized".

VSS-провайдеры для поддержки устройств с LSFS

• Hardware VSS provider - теперь доступен для LSFS-устройств, в том числе с синхронной репликацией.
• Software VSS Provider - доступен для обычных LSFS-устройств.

Asynchronous WAN-replication - возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ.

• Теперь возможна репликация даже на очень медленных каналах.
• Пофикшено монтирование снапшотов.
• Улучшен алгоритм репликации.
• Небольшие доработки в механизме поддержки VAAI.

Скачать новую StarWind SAN V8 Beta 3 можно по этой ссылке. Release notes доступны тут.

Компания NetApp представила свои новые аппаратные платформы, отвечающие требованиям к производительности приложений, работающих с большими объемами данных. Представленные обновления полностью соответствуют инновационной стратегии NetApp, направленной на разработку ускоренных при помощи флэш-технологий и интегрируемых в облачные архитектуры решений хранения данных для широкого спектра разделяемых и специализированных ИТ-инфраструктур. Более подробно узнать о решениях NetApp, протестировать и заказать их можно на сайте компании ИТ-ГРАД.

Флеш-массив NetApp EF550

Массив NetApp EF550 Flash Array разработан для высокопроизводительных приложений, допустимое время ожидания для которых исчисляется долями миллисекунды.

Флэш-массив NetApp EF550® обеспечивает исключительную производительность, эффективность ИТ и надежность для критически важных приложений, увеличивая скорость их работы и сокращая время ожидания.

СХД корпоративного класса NetApp EF550 на базе дисков SSD позволяет:

• ускорить процессы бизнеса благодаря времени отклика, составляющему всего доли миллисекунды;
• устранить избыточное выделение ресурсов и повысить эффективность ИТ;
• добиться операционной производительности, эквивалентной работе 1000 традиционных дисков (15 000 об/мин), используя корпус 2U, который задействует всего 5% пространства стойки, ресурсов питания и охлаждения;
• быстро определять и устранять возможные проблемы с помощью расширенных возможностей мониторинга и проактивного устранения неисправностей;
• обеспечить защиту от потери данных и устранить простои благодаря копиям NetApp Snapshot, удаленной репликации и прочим функциям защиты данных;
• выполнять репликацию данных на СХД EF550 или NetApp E-Series;
• воспользоваться преимуществами корпоративной программной платформы ПО SANtricity.

Высокие показатели IOPS, время ожидания, составляющее всего доли миллисекунды, возможность масштабирования и надежность корпоративного класса флэш-массива NetApp EF550 позволяют ускорить выполнение рабочих процессов и быстрее получить желаемые результаты.

Обновления E-Series – E2700 и Е5500

E-Series включена в линейку решений NetApp для блочных систем хранения данных с повышенной производительностью. Системы E-Series легко масштабируются и предназначены для рабочих нагрузок, требующих 99,999% надежности при устойчиво высокой производительности. 

Новый массив хранения данных NetApp E2700 SAN

Масштабируемая NetApp E2700 представляет собой решение общего назначения для хранения данных приложений, которое подходит для филиалов, удаленных офисов и предприятий среднего бизнеса. На выбор доступны три вида полок — 4U/60, 2U/24 и 2U/12, а также три интерфейса для подключения: FC, iSCSI или SAS. E2700 интегрируется с основными приложениями, включая системы VMware, Exchange, SQL и Oracle.

NetApp E2700 позволяет:

• добиться высочайшего в своем классе уровня производительности для широкого ряда баз данных и других транзакционных приложений;
• упростить и снизить затраты на управление данными с высокой пропускной способностью с помощью конфигурируемой архитектуры, простой в использовании и установке;
• оптимизировать производительность, сократить время ожидания, увеличить пропускную способность и показатель IOPS;
• обеспечить бесперебойность операций с помощью гибкой интеграции приложений;
• масштабировать дисковое пространство по мере роста предприятия.

Как и другие NetApp E-Series, E2700 использует надежное, простое в использовании и экономичное ПО для управления СХД SANtricity.

Это программное обеспечение позволяет повысить уровень производительности и эффективности, обеспечивает динамическое распределение дисковых ресурсов и управление RAID, а также включает в себя технологию Intelligent Cache Tiering (разделение уровней хранения с помощью интеллектуального кэширования) и расширенные возможности защиты данных, в том числе репликацию и аварийное восстановление данных.

Высокопроизводительная система E5500 расширяет возможности защиты данных благодаря использованию инструментального пакета SANtricity с функциями репликации данных и гибким интерфейсом. Система предлагается с дисками iSCSI объемом 10 Гбайт и дисками FC объемом 16 Гбайт.

Программа NetApp AutoSupport обеспечивает пользователям возможность контроля всего предприятия и содержит встроенные средства аналитики для проактивного управления. E5500 может поддерживать объем памяти до 1,5 Пбайт на одну систему, необходимый для крупномасштабных систем обработки данных.

За консультацией по данному оборудованию обращайтесь в компанию ИТ-ГРАД.

Мы уже немало писали про кластеры хранилищ VMware Virtual SAN (последнее - тут и тут), а сегодня рассмотрим механизм работы запросов на чтение блоков, который описал в своем блоге Duncan Epping.

Итак, схема кластера VMware Virtual SAN:

Здесь мы видим такую картину - виртуальная машина находится на хосте ESXi-01, а ее блоки размером 1 МБ размещаются на хранилищах разных хостов. При этом блоком 1 владеет ESXi-01, а блоком 2 - ESXi-03. Хост ESXi-02 не принимает участия в обработке запросов ввода-вывода.

Схема работы запроса на чтение проста - сначала проверяется наличие блока в кэше на чтение (Read cache), и если там блока не оказывается, то проверяется Write buffer на хранилище SSD (если блок еще не успел записаться на HDD) и непосредственно сам HDD-диск. В данном случае блок 1 нашелся на SSD-диске в кэше на чтение.

Второй же блок обслуживается хостом ESXi-03, но его не оказалось в кэше на чтение, и он читается с HDD-диска. Тут надо отметить, что кластер Virtual SAN помещает блоки в кэш на чтение только на тех хостах, которые активно обслуживают этот блок и владеют им, а те хосты, которые просто хранят копию данных - в Read cache таких блоков не помещают.

Продолжаем рассказывать о решении StarWind iSCSI SAN V8, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин. Не так давно мы о новых возможностях второй беты продукта StarWind V8, а в первых числах этого года появилась обновленная (третья) бета этого продукта, которую можно скачать по этой ссылке: http://www.starwindsoftware.com/starwind-v8-beta.

Напомним основные новые возможности StarWind V8 Beta 3:

• L2 Flash Cache - кэш уровня L2, который работает непосредственно с кэшем уровня L1 в RAM, что существенно улучшает производительность.
• Файловая система LSFS, которая изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего). Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
• Inline-дедупликация StarWind, которая не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.
• Simplified and improved GUI - улучшенный интерфейс мастеров развертывания хранилищ для Windows Server 2012 с поддержкой скриптов PowerShell.
• Возможность интеграции с механизмом SMI-S для Windows Server 2012 R2.
• Massive Scale-Out storage architecture - возможность масштабирования узлов кластера хранилищ до любого числа (а не только 3 как сейчас).
• Asynchronous WAN-replication - возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ.
• Поддержка примитивов VAAI для устройств на одном узле и устройств с синхронной репликацией: поддерживаются команды WRITE SAME, EXTENDED COPY, ATS.
• Репликация конфигурации узла, включая информацию о снапшотах, что позволяет в случае сбоя сохранить созданную оригинальную конфигурацию и реплицировать ее уже, например, на третий узел.

Мы уже много писали о технологии VMware Virtual SAN (VSAN), которая позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бетаэтого решения, кроме того мы не так давно писали о производительности VSAN тут.

В этой заметке (на базе статьи Дункана) мы поговорим о том, как кластер VSAN обрабатывает сбои различного типа, и как происходит восстановление работоспособности виртуальной машины без ее простоя.

Итак, в нормальном режиме функционирования, при значении параметра FailuresToTolerate равном 1, который означает, какое количество отказов хостов может пережить кластер хранилищ, реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно заметить 5 особенностей кластера VMware VSAN:

• Виртуальный диск VMDK и его реплика всегда находятся на разных хост-серверах VMware vSphere.
• ВМ не обязательно должна исполняться на том хосте ESXi, на дисках которого находятся ее хранилища.
• Компонент witness находится на третьем по отоношению к виртуальному диску и его реплике хосте, чтобы создать определенность на случай разделения сети VSAN (где окажется 2 компонента из набора "vmdk-реплика-witness" - тот сегмент и будет определяющим).
• Сеть VSAN используется для операций ввода-вывода и определения доступности.
• Реплика VMDK-диска вместе с основной копией образуют RAID-1 массив, который увеличивает производительность операций чтения в виртуальной машине, так как для чтения используются оба хранилища.

Кроме того, вследствие особенностей реализации кластера VSAN, надо понимать, что команды ввода-вывода не применяются к диску данных виртуальной машины, пока не пришло подтверждение об их записи на реплике. Но подтверждение приходит не от HDD-диска, где находятся данные ВМ (это было бы очень медленно), а от SSD-диска, который используется как энергонезависимый Write Buffer для команд ввода вывода. Таким образом, этот буфер (и данные, само собой) зеркалирован в рамках дисковой группы на другом хосте ESXi.

Теперь рассмотрим различные виды сбоев в кластере VSAN.

1. Ломается диск дисковой группы, где исполняется виртуальная машина.

Выглядит это так:

В этом случае такой диск сразу же помечается как "degraded", а команды ввода-вывода перенаправляются на другой хост-сервер VMware ESXi. При этом виртуальная машина этого не замечает, так как переключается на работу с SSD-буфером/кэшем и HDD-дисками другого хоста мгновенно (данные на момент сбоя были синхронизированы, ничего не потерялось).

Одновременно с этим сразу же начинается процесс построения реплики на другом хосте ESXi в рамках его дисковой группы, при этом проверяется, достаточно ли там свободных дисковых ресурсов. Если их недостаточно, то механизм VSAN будет ожидать. Как только вы добавите диски/дисковые группы на хостах - сразу же начнется процесс построения реплики (до его окончания машина будет помечена как "degraded").

Тут надо отметить, что в degraded-состоянии скорость записи данных останется прежней, простоя не будет, а вот скорость чтения упадет до построения новой реплики, поскольку второй копии данных пока нет.

2. Отказывает хост VMware ESXi целиком.

В этом случае запускать процесс восстановления сразу же, конечно, не нужно - мало ли что могло случиться с хостом, например, его случайно перезагрузили, или временно пропало сетевое соединение.

В этом случае происходит ожидание в течение 60 минут, и если отказавший хост ESXi не оживет, то начнется процесс создания реплики виртуального диска VMDK на другом хосте. Это время можно изменить в расширенной настройке кластера VSAN.ClomRepairDelay, но пока не известно будет ли это поддерживаться со стороны VMware.

3. Отказ SSD-диска в дисковой группе.

В кластере VMware Virtual SAN поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп.

В данном случае Failure Domain - это вся дисковая группа, включающая в себя SSD-диск, который используется для двух типов операций:

• Read Cache (70% емкости) - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering (30% емкости) - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Таким образом, при отказе SSD-диска, виртуальная машина начинает использовать реплику на уровне всей дисковой группы на другом хосте VMware ESXi. Вот почему выгодно делать две дисковых группы 3HDD+1SSD, чем одну  6HDD+1SSD.

Вот, в общем-то, и все. Более подробно об использовании SSD-дисков, их производительности и ресурсе можно прочитать вот в этой статье.

Как многие знают, в VMware vSphere 5.5 появились возможности Virtual SAN, которые позволяют создать кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бета этого решения, кроме того мы не так давно писали о производительности VSAN тут и тут.

Сегодня же мы поговорим о том, как нужно сайзить хранилища Virtual SAN в VMware vSphere, а также немного затронем тему отказоустойчивости. Более детальную информацию можно найти в VMware Virtual SAN Design & Sizing Guide, а ниже мы расскажем о подходе к планированию хранилищ VSAN вкратце.

Объекты и компоненты Virtual SAN

Начнем с простого ограничения по объектам (objects) и компонентам (components), которое есть в VSAN. Виртуальные машины, развернутые на vsanDatastore, могут иметь 4 типа объектов:

• Домашняя директория виртуальной машины Virtual Machine ("namespace directory").
• Объект файла подкачки - swap object (для включенной ВМ).
• Виртуальный диск VMDK.
• Дельта-диски для снапшотов. Каждый дельта-диск - это отдельный объект.

Каждый объект, в зависимости от типа RAID, рождает некоторое количество компонентов. Например, один VMDK, размещенный на двух томах страйпа (RAID 0) рождает два объекта. Более подробно об этом написано вот тут.

Так вот, ограничения тут следующие:

• Максимальное число компонентов на 1 хост ESXi: 3000.
• Максимальное число компонентов для одного объекта: 64 (это включает в себя тома страйпов и также реплики VMDK с других хостов).

На практике эти ограничения вряд ли актуальны, однако о них следует знать.

Сколько дисков потребуется для Virtual SAN

Во второй бета-версии VSAN (и, скорее всего, так будет в релизной версии) поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп. Таким образом, на хосте поддерживается до 5 SSD-дисков и до 35 HDD-дисков. Надо убедиться, что контроллеры хоста поддерживают необходимое количество дисков, а кроме того нужно проверить список совместимости VSAN HCL, который постоянно пополняется.

Также надо учитывать, что кластер хранилищ Virtual SAN поддерживает расширение как путем добавления новых дисков, так и посредством добавления новых хостов в кластер. На данный момент VMware поддерживает кластер хранилищ максимум из 8 узлов, что суммарно дает емкость в дисках в количестве 40 SSD (1*5*8) и 280 HDD (7*5*8).

Сколько дисковой емкости нужно для Virtual SAN (HDD-диски)

Необходимая емкость под размещение VMDK зависит от используемого параметра FailuresToTolerate (по умолчанию 1), который означает, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1, то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно сказать о том, как работает отказоустойчивость кластера Virtual SAN. Если отказывает хост, на котором нет виртуальной машины, а есть только VMDK или реплика, то виртуальная машина продолжает работу с основной или резервной копией хранилища. В этом случае начнется процесс реконструкции реплики, но не сразу - а через 60 минут, чтобы дать время на перезагрузки хоста (то есть если произошел не отказ, а плановая или внеплановая перезагрузка), а также на короткие окна обслуживания.

А вот если ломается хост, где исполняется ВМ - начинается процедура восстановления машины средствами VMware HA, который перезапускает ее на другом хосте, взаимодействуя при этом с Virtual SAN.

Более подробно этот процесс рассмотрен вот в этой статье и вот в этом видео:

Однако вернемся к требующейся нам емкости хранилищ. Итак, если мы поняли, что значит политика FailuresToTolerate (FTT), то требуемый объем хранилища для кластера Virtual SAN равняется:

Capacity = VMDK Size * (FTT + 1)

Что, в принципе, и так было очевидно.

Сколько дисковой емкости нужно для Virtual SAN (SSD-диски)

Теперь перейдем к SSD-дискам в кластере VSAN, которые, как известно, используются для вспомогательных целей и не хранят в себе данных виртуальных машин. А именно, вот для чего они нужны (более подробно об этом тут):

• Read Cache - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Так каковы же рекомендации VMware? Очень просты - под SSD кэш и буфер неплохо бы выделять 10% от емкости HDD-дисков хоста. Ну и не забываем про значение FailuresToTolerate (FTT), которое в соответствующее число раз увеличивает требования к емкости SSD.

Таким образом, необходимая емкость SSD-хранилищ равна:

Capacity = (VMDK Size * 0.1) * (FTT + 1)

Ну и напоследок рекомендуем отличнейший список статей на тему VMware Virtual SAN:

• VSAN Part 1 – A first look at VSAN
• VSAN Part 2 – What do you need to get started?
• VSAN Part 3 – It is not a Virtual Storage Appliance
• VSAN Part 4 – Understanding Objects and Components
• VSAN Part 5 – The role of VASA
• VSAN Part 6 – Manual or Automatic Mode
• VSAN Part 7 – Capabilities and VM Storage Policies
• VSAN Part 8 – The role of the SSD
• VSAN Part 9 – Host Failure Scenarios and vSphere HA interop
• VSAN Part 10 – Changing VM Storage Policy on-the-fly

Мы уже писали о технологии VMware Virtual SAN, которая сейчас находится в режиме бета-тестирования. Кроме того, мы затрагивали тему производительности виртуальных ПК VMware Horizon View на хранилищах Virtual SAN (там про то, что VSAN масштабируется почти без потерь производительности).

Сегодня мы хотим рассказать еще о двух вещах. Во-первых, компания VMware выпустила обновление беты Virtual SAN, которое получило следующие новые возможности:

• AHCI fix - как писала VMware ранее, была проблема с контроллерами AHCI, которая приводила к потере данных на устройствах VSAN (см. PDL, Permanent Device Loss). Теперь эту проблему исправили, и можно продолжать тестирование на этих контроллерах.

• New RVC Commands - теперь в Ruby Virtual Console, которая входит в состав VMware vCenter 5.5, есть команды по управлению хранилищами в пространстве имен spbm (Storage Policy Based Management). Существующие политики можно найти в папке "~/storage/vmprofiles".

• PowerCLI fling - многим пользователям интересна автоматизация задач в VMware vCloud Suite. Теперь и для VSAN есть набор командлетов PowerCLI, которые позволяют управлять хранилищами VSAN. Более подробно об этом здесь.

• Limit Changes - в первой бета-версии дисковая группа могла иметь 1 SSD-Накопитель и до 6 HDD-дисков, но поскольку есть серверы, в которых восемь слотов, то HDD-дисков теперь поддерживается до 7 штук (SSD по-прежнему один).

Во-вторых появилась третья статья в серии про Virtual SAN - "VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 3" из цикла статей, где делаются всяческие замеры производительности хранилищ VSAN.

В этот раз сравнивалось некий дисковый массив "all flash storage array", который работает на SSD-накопителях, и 7-ми и 8-ми узловые кластеры Virtual SAN. Результаты в очках, поставленных VDImark (View Planner QoS), поставленные кластеру из хостовых хранилищ и дисковому массиву:

Напомним, что очки VDImark - это число виртуальных машин, которое может быть запущено на данной аппаратной конфигурации с соблюдением определенного порогового значения для операций (на самом деле минимум 95% операций должны попасть в эти трешхолды для ВМ, чтобы их засчитали).

Результаты тестов оказались весьма неплохими. Картинка для тестов по времени отклика операций группы А (интерактивные операции пользователя):

Группа B:

Вывод: Virtual SAN - очень неплох в сравнении с нативной производительностью какого-то SSD-массива (VMware, что это за массив-то??).

Ну и ссылки на все статьи цикла:

• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 1
• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 2
• VDI Benchmarking Using View Planner on VMware Virtual SAN – Part 3

Уже довольно давно мы писали про техники кэширования в продукте StarWind iSCSI SAN & NAS, который предназначен для создания отказоустойчивых iSCSI-хранилищ под виртуальные машины. Эти техники постоянно совершенствуются (см., например, новые возможности StarWind V8 Beta 2) и иногда в разы увеличивают быстродействие виртуальных машин, особенно в условиях высоких требований к подсистеме ввода-вывода.

У некоторых пользователей возникает вопрос - а нужно ли использовать кэш StarWind, когда на сервере используется SAS-адаптер со своим кэшем, например, HP Smart Array P420, имеющий на борту 1GB RAM. На форуме StarWind Антон отвечает на этот вопрос следующим образом:

• У кэша контроллера весьма ограниченный объем, а StarWind может использовать очень большой объем RAM для оптимизации ввода-вывода.
• Кэш контроллера медленный, так как использует шину PCIe, а кэш StarWind - быстрый, так как использует шину оперативной памяти.
• Кэш контроллера небезопасен - только одна копия данных. При использовании кэширования StarWind метаданные дублируются и даже "триплируются" при использовании трехузлового кластера. Вероятность, что все хосты кластера хранилищ упадут одновременно - очень низка.
• Кэш контроллера работает только для одного узла, то есть когда ВМ переезжает с этого узла - она уже не имеет доступа к своему кэшу. StarWind же имеет умную систему распределенного кэша между узлами, и когда виртуальная машина переезжает на другой хост кластера хранилищ, она продолжает его использование.

Таким образом, вывод прост - конечно же, включайте кэширование на уровне SCSI-адаптера, но не подразумевайте это как альтернативу кэшированию StarWind, так как последнее - более умная и эффективная технология, разработанная изначально для виртуальных машин.

Мы уже писали про распределенный кэш на SSD-накопителях локальных дисков серверов ESXi, который имел рабочее название vFlash, а затем превратился в полноценную функцию VMware vSphere Flash Read Cache платформы VMware vSphere 5.5.

Сегодня мы хотим обратить внимание на два интересных документа, которые раскрывают подробности использования этой технологии.

Напомним, что Flash Read Cache позволяет использовать кэширование данных только на чтение для дисков VMDK виртуальных машин, работает она на уровне гипервизора и существенно улучшает производительность виртуальных машин, которые интенсивно используют подсистему ввода-вывода для операций на чтение. Очевидно, что SSD-кэш, который по производительности находится между оперативной памятью и обычными дисками, существенно повышает быстродействие в системах, где периодически наблюдается недостаток ресурсов RAM. Все это дело работает в кластере до 32 хостов ESXi.

Итак, первый документ о том как работает технология Flash Read Cache - "What’s New in VMware vSphere Flash Read Cache":

В этом документе описано, как работает инфраструктура vFlash в рамках виртуальной инфраструктуры vSphere, для каких целей можно использовать данную технологию, требования, а также шаги по установке и настройке этого механизма.

Второй документ - это официальный FAQ VMware по технологии Flash Read Cache - "VMware vSphere Flash Read Cache 1.0 FAQ". Так как она появилась впервые, и не все технические особенности ясны администраторам, в документе даны ответы аж на 67 вопросов.

Интересные факты из этого FAQ:

• В качестве интерфейсов накопителей поддерживаются SATA, SAS и PCI Express.
• До 8 устройств vFlash на один хост ESXi и до 4 ТБ емкости на устройство (до 400 ГБ на один VMDK). На один контейнер VFFS (то есть на хост) поддерживается до 32 ТБ.
• В качестве хранилищ ВМ механизмом поддерживаются тома VMFS/NFS/vRDM (pRDM не поддерживается).
• Настраивается только через Web Client.
• При изменении настроек vFlash все кэши для дисков сбрасываются.
• Thin provisioning не поддерживается технологией vFlash.
• При миграции виртуальной машины средствами vMotion можно использовать 2 политики: Always migrate the cache contents (copy) - кэш копируется вместе с ВМ и Do not migrate the cache contents (drop) - кэш очищается. Техники VMware HA / SVMotion также полностью поддерживается.
• Механизм VMware DRS при миграции не затрагивает машины с включенным Virtual Flash Read Cache.
• Операции, которые очищают кэш ВМ: suspend, изменение конфигурации, удаление, перезапуск машины или хоста, восстановление из снапшота. Операции, которые не очищают кэш: снятие снапшота, клонирование, миграция vMotion, fast suspend/resume.
• В vCenter есть 3 специальных метрики для мониторинга vFlash (IOPS, Latency и объем кэша).
• Кэшем vFlash можно управлять через ESX CLI: get –m <module> -c <cache file name>
• Файлы кэша vFlash находятся в следующей директории на хосте: /vmfs/volumes/vffs/vflash

Информацию об официально поддерживаемых механизмом VMware vSphere Flash Read Cache устройствах можно найти по этой ссылке: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=vfrc

На сайте проекта VMware Labs, известного всем администраторам VMware vSphere, появились интересные утилиты для управления инфраструктурой VMware vSphere через PowerShell - командлеты PowerCLI Extensions, объединенные в отдельный PowerShell-модуль VMware.VimAutomation.Extensions.

Эти командлеты реализуют управление следующими новыми компонентами VMware vSphere 5.5:

• vSphere Flash Read Cache
• VMware Virtual SAN

Для использования этих командлетов вам понадобится:

• Microsoft PowerShell v2 или более поздний
• Фреймворк vSphere PowerCLI v5.5 R1

Скачать VMware PowerCLI Extensions можно по этой ссылке. Инструкция по установке - здесь.

Сегодня на VM Guru день новостей об обучении. Заметкой выше мы написали о том, что компания Microsoft сделала ресурс Virtualization Square, который позволит ИТ-специалистам бесплатно не только пройти онлайн-обучение, но и сдать сертификационный экзамен.

Компания VMware, видимо будучи в курсе этой новости, объявила об обновлении своего портала vmwarewalkthroughs.com (о нем мы уже писали вот тут), на котором можно в интерактивном режиме пройти по шагам конфигурации различных продуктов в интерфейсе соответствующего решения.

Теперь на обучающем портале VMware добавились следующие демо решений:

• http://vmwarewalkthroughs.com/NSX/ 
  Наглядная конфигурация решения VMware NSX, эксклюзив, которого больше нигде не найти.
• http://vmwarewalkthroughs.com/vSOM/
  Показывается как настроить VMware vSphere HA, DRS, vSphere Replication, решение vCOPS и многое другое.
• http://vmwarewalkthroughs.com/vCloudSuite5-5/
  Информация о продуктах vCloud Director, App HA, Flash Read Cache и другое.
• http://vmwarewalkthroughs.com/VSAN/
  Как настроить хранилища VMware Virtual SAN, задать политики и прочее.

Для инженерного состава - самое то, чтобы начать знакомство с решениями VMware.

Продолжаем рассказывать о решении StarWind iSCSI SAN V8, предназначенном для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин, которое имеет множество новых возможностей, о которых мы писали в посте про первую бету продукта StarWind V8.

Недавно вышла вторая бета-версия продукта StarWind V8 Beta 2, все в том же зомби-стиле:

Основные новые возможности StarWind V8 Beta 2:

• L2 Flash Cache - кэш уровня L2, который работает непосредственно с кэшем уровня L1 в RAM, что существенно улучшает производительность.
• Файловая система LSFS, которая изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего). Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что также существенно увеличивает производительность.
• Inline-дедупликация StarWind, которая не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.
• Simplified and improved GUI - улучшенный интерфейс мастеров развертывания хранилищ для Windows Server 2012 с поддержкой скриптов PowerShell.
• Возможность интеграции с механизмом SMI-S для Windows Server 2012 R2.

Новые возможности, относящиеся именно к Beta 2:

• Massive Scale-Out storage architecture - возможность масштабирования узлов кластера хранилищ до любого числа (а не только 3 как сейчас).
• Asynchronous WAN-replication - возможность асинхронной репликации между узлами и возможность создания катастрофоустойчивого решения для хранилищ.
• Поддержка примитивов VAAI для устройств на одном узле и устройств с синхронной репликацией: поддерживаются команды WRITE SAME, EXTENDED COPY, ATS.
• Репликация конфигурации узла, включая информацию о снапшотах, что позволяет в случае сбоя сохранить созданную оригинальную конфигурацию и реплицировать ее уже, например, на третий узел.

Скачать StarWind V8 Beta 2 можно по этой ссылке, а лицензионный ключ можно взять тут.

Невозможно ощутить все преимущества виртуализации, не имея системы хранения данных. В рамках семинара "Критерии выбора СХД под виртуализацию" на примере СХД NetApp специалисты компании ИТ-ГРАД расскажут про основные критерии, на которые стоит обратить внимание при выборе системы хранения данных для построения виртуальной инфраструктуры.

Критерии включают:

• Универсальное, мультипротокольное хранилище 
  (FC+iSCSI+FCoE+NFS+CIFS/SMB2.0);
• Дедупликацию данных;
• Flash Cache;
• Thin Provisioning;
• Снэпшоты;
• FlexClone;
• Интеграцию с vCenter;
• VAAI, Multitenant, OnCommand Insight и т.д.

Тип мероприятия:  семинар
Дата проведения:  17.10.2013 10:00:00
Место проведения:  информация появится позднее

Регистрация

Сразу после релиза обновленной версии платформы vSphere 5.5 компания VMware выпустила очень интересный и полезный документ Performance Best Practices for VMware vSphere 5.5, в котором рассматриваются аспекты производительности серверов VMware ESXi и виртуальных машин уже с учетом функциональности новой версии.

Например, теперь в документе описаны следующие фичи в контексте производительности:

• Функции кэширования на SSD-накопителях vSphere Flash Read Cache, о которых мы писали вот тут. Они увеличивают производительность за счет применения кэша на чтение для операций ввода-вывода виртуальных машин.
• Возможность VMware Virtual SAN (VSAN), о которой мы писали тут. Она позволяет использовать локальные ресурсы хостов ESXi для построения распределенной инфраструктуры хранения виртуальных машин.
• База данных VMware vFabric Postgres database (vPostgres).

Кроме того, были обновлены и дополнены следующие темы в документе (который уже можно смело называть книгой, так как занимает он 90 страниц):

• Использование нагрузок в ВМ, чувствительных к скорости подсистемы ввода-вывода и сетевому взаимодействию (интересна также статья в тему)
• Техники NUMA и Virtual NUMA (vNUMA)
• Техники экономии памяти хоста (Memory overcommit)
• Технология Large memory pages
• Техника Receive-side scaling (RSS), как в гостевых ОС, так и для адаптеров 10 Gigabit Ethernet
• Средства миграции VMware vMotion, Storage vMotion, а также Cross-host Storage vMotion
• Техники балансировки нагрузки VMware Distributed Resource Scheduler (DRS) и экономии электропитания Distributed Power Management (DPM)
• Обновленный (а точнее полностью переписанный) VMware Single Sign-On Server (об этом у нас тут)

Мы уже немало писали о новой версии продукта StarWind iSCSI SAN 8 (тут и тут), предназначенного для создания отказоустойчивых iSCSI-хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V. Не так давно проходило закрытое бета-тестирование StarWind v8, а сейчас уже публичная бета-версия этого продукта доступна для загрузки.

Новые возможности этой бета-версии:

• L2 Flash Cache - кэш уровня L2, который работает непосредственно с кэшем уровня L1 в RAM, что существенно улучшает производительность.
• Файловая система LSFS изначально работает с большими блоками данных, что положительно сказывается на сроке службы флеш-накопителей (SSD), на которых размещаются виртуальные машины (это дело недалекого будущего)
• Файловая система LSFS преобразовывает small random writes в большие последовательные операции записи, что существенно увеличивает производительность.
• Inline-дедупликация StarWind, которая не создает нагрузку на подсистему хранения и не "крадет" IOPS'ы у продуктивного хранилища.
• Simplified and improved GUI - улучшенный интерфейс мастеров развертывания хранилищ для Windows Server 2012 с поддержкой скриптов PowerShell.
• Возможность интеграции с механизмом SMI-S для Windows Server 2012 R2.

В состав возможностей следующей беты StarWind v8 будут также включены следующие возможности:

• Возможность масштабирования узлов кластера хранилищ до любого числа (а не только 3 как сейчас).
• Поддержка механизма виртуальных ленточных библиотек (Virtual tape library, VTL).
• Возможность асинхронной репликации между узлами.

Скачать StarWind v8 Beta можно по этой ссылке.

Некоторое время назад мы уже выкладывали интерактивные демо продуктов VMware, но с тех пор уже много воды утекло, и демки устарели. На прошедшей конференции VMworld 2013 компания VMware анонсировала новые версии своих продуктов, например, VMware vSphere 5.5 и vCloud Director 5.5, а к ним она приложила интерактивные демо, воспользоваться которыми в целях обучения может любой желающий.

Вот какие функции продуктов VMware можно посмотреть онлайн, не устанавливая их на свои серверы:

• vSphere Data Protection 5.5 (VDP) – резервное копирование виртуальных машин.
• vSphere 5.5 AppHA (AppHA) - мониторинг доступности приложений в виртуальных машинах (новая функция vSphere 5.5).
• vCloud Director 5.5 (VCD) - новая версия решения для управления облачной инфраструктурой.
• vSphere 5.5 Replication (VR) - техника репликации виртуальных машин.
• vSphere 5.5 vFlash Read Cache (VFRC) - новая возможность использования кэша на флэш-дисках, о которой мы писали вот тут.
• VMware Virtual SAN (vSAN) - возможности распределенного хранения виртуальных машин на локальных дисках серверов, о которых мы писали вот тут.

Традиционно, демо продуктов VMware - это графическая консоль с инструкциями куда нажимать и зачем. Очень удобно:

Компания ИТ-ГРАД приглашает заинтересованных ИТ-профессионалов, менеджеров и ИТ-директоров на мероприятие "Критерии выбора СХД под виртуализацию. Санкт-Петербург".

Невозможно ощутить все преимущества виртуализации, не имея системы хранения данных. В рамках данного семинара на примере СХД NetApp специалисты компании ИТ-ГРАД расскажут про основные критерии, на которые стоит обратить внимание при выборе системы хранения данных для построения виртуальной инфраструктуры.

Критерии включают:

• Универсальное, мультипротокольное хранилище 
  (FC+iSCSI+FCoE+NFS+CIFS/SMB2.0);
• Дедупликацию данных;
• Flash Cache;
• Thin Provisioning;
• Снэпшоты;
• FlexClone;
• Интеграцию с vCenter;
• VAAI, Multitenant, OnCommand Insight и т.д.

Тип мероприятия:  семинар.
Дата проведения:  19.09.2013 19:00.
Место проведения:  Деловой клуб "Клевер", ул. Кирочная, д.9, Санкт-Петербург.

ЗАРЕГИСТРИРОВАТЬСЯ

Не так давно мы уже писали о планируемых новых возможностях VMware vSphere 5.5, однако большинство новых функций были описаны в общих чертах, кроме того, до последнего момента так и не было окончательно известно, что же еще нового появится в vSphere 5.5. На проходящей сейчас конференции VMworld 2013 компания VMware наконец-то объявила о выходе обновленной платформы VMware vSphere 5.5, которая стала еще более мощным средством для построения виртуальных инфраструктур.

Был тут случай недавно - пишет мне товарищ, дескать, что это мы пост разместили с инфой, которая под NDA. А откуда мы должны знать, что находится под NDA, а что не под NDA? И вообще с какой стати все эти заморочки с NDA? Я вообще на тему продуктов чьих-то NDA никогда не подписывал и подписывать не собираюсь. А если появляется утечка с новыми возможностями продукта или компании - это никакой нахрен не слив инфы под NDA, а самая обычная и уже набившая оскомину реклама - радуйтесь.

Или вот приходит нам рассылка про новую версию vCloud Director, а внизу написано:

***** Confidential Information ***** 
Do not forward information about this program or release to anyone outside of those directly involved with beta testing. This information is highly confidential.

Information contained in this email, including version numbers, is not a commitment by VMware to provide or enhance any of the features below in any generally available product.

Или вот NVIDIA пишет:

Обращаю ваше внимание, что информация брифинга находится под NDA до 17:00 по Москве вторника, 23-го июля.

И чо? А если я им в письме напишу, что им нельзя мыться 3 месяца - они будут этот наказ соблюдать?

Так что, уважаемые вендоры, надеюсь, вам понятна позиция VM Guru с вашими NDA. Если мы их не подписывали - не пишите нам ничего на эту тему, так как эти письма отправляются прямиком в трэш по ключевому слову "NDA".

Вон у Apple тоже, конечно, утечки бывают, но в целом-то - хрен узнаешь, когда этот новый айфон выйдет. Поэтому в этом посте мы с удовольствием расскажем о новых возможностях VMware vSphere 5.5 на основе информации, взятой из сети интернет (также об этом есть на блоге Андрея и Виктора - http://vmind.ru/2013/08/15/chego-zhdat-ot-vmware-vsphere-5-5/). Естественно, не все из этих фичей могут оказаться в релизной версии, и это, само собой, не полный их список.

New OS Support

Наряду с поддержкой Windows 8.1 (ожидается в VMware View 5.5) будут поддерживаться последние релизы гостевых ОС Linux: Ubuntu, Fedora, CentOS, OpenSUSE и другие дистрибутивы.

VMware Hardware Version 10

Теперь появится новое поколение виртуального аппаратного обеспечения версии 10. Это добавит новых возможностей виртуальным машинам с точки зрения динамических сервисов виртуализации. Для редакции vSphere Enterprise Plus будет поддерживаться до 128 vCPU.

Administrative UI (Web Client)

Новая версия веб-клиента vSphere Web Client теперь является единственным средством управления инфраструктурой виртуализации.

• Улучшенный интерфейс, большое количество фильтров и вкладка "recent objects", позволяющая получить быстрый доступ к объектам.
• Улучшения по времени отклика интерфейса и возможность управлять большим числом объектов.

vSphere Replication - теперь доступны следующие возможности по репликации виртуальных машин:

• Возможность репликации виртуальных машин между кластерами для машин не с общими хранилищами (non-shared storage).
• Поддержка нескольких точек для восстановления целевой реплицируемой машины. Это защищает сервисы от логических повреждений данных, изменения в которых реплицируются на резервную площадку.
• Storage DRS Interoperability - возможность реплицируемых машин балансироваться по хранилищам средствами технологии Storage vMotion без прерывания репликации.
• Simplified Management - улучшенная интеграция с vSphere Web Client, что позволяет мониторить процесс репликации в различных представлениях vCenter.
• Поддержка технологии VSAN (см. ниже) - теперь машины на таких хранилищах поддерживаются средствами репликации.
• vCenter Orchestrator - теперь это средство автоматизации существенно оптимизировано в плане масштабируемости и высокой доступности. Разработчики теперь могут использовать упрощенные функции диагностики в vCenter Orchestrator client.

Virtual SAN

О возможностях VMware Distributed Storage и vSAN мы уже писали вот в этой статье. Virtual SAN - это полностью программное решение, встроенное в серверы VMware ESXi, позволяющее агрегировать хранилища хост-серверов (SSD и HDD) в единый пул ресурсов хранения для всех хостов, что позволяет организовать ярусность хранения с необходимыми политиками для хранилищ.

Поддержка томов vVOL

Также мы писали о поддержке виртуальных томов vVOL - низкоуровневых хранилищ для каждой из виртуальных машин, с которыми будут позволены операции на уровне массива, которые сегодня доступны для традиционных LUN - например, снапшоты дискового уровня, репликация и прочее. Проще говоря, VMDK-диск машины можно будет хранить как отдельную сущность уровня хранилищ в виде vVOL, и с ней можно будет работать отдельно, без влияния на другие ВМ этого массива.

VMware Virtual Flash (vFlash)

О возможностях VMware Virtual Flash (vFlash) мы уже писали вот в этой статье. vFlash - это средство, позволяющее объединить SSD-ресурсы хост-серверов VMware ESXi в единый пул, используемый для задач кэширования, чтобы повысить быстродействие виртуальных машин. vFlash - это фреймворк, позволяющий сторонним вендорам SSD-накопителей и кэш-устройств использовать собственные алгоритмы для создания модулей обработки кэшей виртуальных машин (плагины vFlash Cache Modules). Будет реализован и собственный базовый алгоритм VMware для работы с кэшем.

Virtual Machine File System (VMFS)

Теперь VMware vSphere 5.5 поддерживает vmdk-диски объемом более 2 TБ. Теперь объем виртуального диска машины может быть размером до 64 ТБ. Несколько больших файлов теперь могут храниться в одном vmdk. Это поддерживается только для VMFS 5.

vCloud Director

Теперь продукт доступен как виртуальный модуль (Virtual Appliance) - можно использовать как встроенную так и внешнюю БД. Этот модуль по-прежнему не будет рекомендован для продакшен-среды. Рекомендуют использовать его для апробации решения.

Был существенно улучшен Content Catalog:

• Улучшена производительность и стабильность синхронизации
• Расширяемый протокол синхронизации
• Возможность самостоятельной загрузки элементов каталога (OVF)

Кроме того, для интерфейса управления теперь поддерживается больше браузеров и ОС (в том числе поддержка Mac OS).

vCloud Networking & Security

В составе vSphere 5.5 этот продукт будет иметь следующие улучшения:

• Улучшенная поддержка Link Aggregation Control Protocol (LACP) - теперь поддерживается 22 алгоритма балансировки и до 32 физических соединений в агрегированном канале.
• Улучшения производительности и надежности агрегированного канала.

Кроме того, вместо vCloud Networking and Security с октября выходит новый продукт VMware NSX.

Security Features

Теперь появится распределенный сетевой экран (Distributed Firewall), являющийся одним из ключевых компонентов концепции Software Defined Datacenter. Он работает на уровне гипервизора каждого из хостов VMware ESXi, а на уровне централизованной консоли доступен мониторинг проходящих пакетов от абсолютно каждой виртуальной машины.

Политики этого сетевого экрана определяются на уровне VXLAN, поэтому нет нужды оперировать с ним на уровне IP-адресов. Ну и так как поддержка этого распределенного фаервола реализована на уровне гипервизора - то политики перемещаются вместе с виртуальной машиной, если она меняет хост средствами vMotion.

Более подробно об этом можно прочитать тут.

vCenter Site Recovery Manager

Теперь vCenter SRM будет поддерживать технологию vSAN вместе с vSphere Replication, работать с технологиями Storage DRS и Storage vMotion. Кроме того, добавлена поддержка нескольких точек восстановления реплик (Multi-Point-In-Time snapshots) при исполнении плана аварийного восстановления.

VMware vCenter Multi-Hypervisor Manager (MHM) 1.1

Об этом продукте мы уже писали вот тут. Теперь он будет поддерживать гипервизор Microsoft Hyper-V 3.0 в Windows Server 2012 R2 (а также более ранние его версии). Также появилась возможность холодной миграции ВМ с хостов Hyper-V на VMware vSphere.

Single Sign-On 2.0 (SSO)

В новой версии единого средства аутентификации продуктов VMware теперь появится улучшенная и новая поддержка следующих компонентов:

• vSphere
• vCenter Orchestrator
• vSphere Replication
• vSphere AppHA (новый продукт, который будет анонсирован на VMworld)
• vCloud Director
• vCloud Networking and Security (vCNS)

Технология VMware vDGA для VMware Horizon View 5.5

О технологии NVIDIA VGX мы уже писали вот тут, тут и тут. Согласно этой презентации, уже скоро мы увидим возможности шаринга и выделение GPU отдельным виртуальным машинам:

Ну что знал - рассказал. В целом, ничего революционного. Поддержку Fault Tolerance для 4-х vCPU обещают в VMware vSphere 6.0.

Виктору спасибо за ссылки. Вот еще немного о предстоящем выходе обновленной платформы - http://vmind.ru/2013/08/13/vmware-vsphere-5-5/.

Вот и стали появляться первые сравнения платформ виртуализации VMware vSphere 5.1 и еще невышедшего Microsoft Hyper 2012 R2 (в составе Windows Server 2012 R2). О сильных и слабых сторонах продуктов мы уже давно не спорим, так как дело это пустое, а вот таблички из статьи, содержащие немало фактического материала, спорщикам пригодятся.

Итак, что мы имеем в плане максимальных параметров, вычислительных ресурсов и масштабирования:

Сравнение vSphere 5.1 и Hyper-V 2012 R2 в плане хранилищ (Storage):

В плане сетевого взаимодействия различия следующие:

О том, что лучше - VMware vSphere или Microsoft Hyper-V, можно рассуждать бесконечно, но однозначно можно сказать только одно - Hyper-V год от года становится значительно функциональнее, а вот VMware основные усилия по улучшению продукта направляет только на издание Enterprise Plus, купить которое не каждой компании по средствам.

Хотим в этом посте пригласить вас в Центр компетенции компании ИТ-ГРАД, который находится в Санкт-Петербурге. Он сочетает в себе опции демонстрационного центра и лаборатории, предназначенной для тестирования существующих решений и их последующей оптимизации, а также для создания персональных решений в процессе совместной работы производителя и заказчика.

Центр компетенции позволяет решать следующие задачи:

• Функциональное и нагрузочное тестирование СХД NetApp на реальных задачах.
• Апробация и моделирование важных изменений в тестовой среде.
• Знакомство с возможностями интеграции с системами виртуализации и приложениями.
• Точная оценка эффективности внедрения СХД NetApp в конкретном проекте.
• Концентрация компетенций по технологиям NetApp, получение консультаций, обучение.
• Организация склада запасных частей.

• Перед вами стоит вопрос выбора системы хранения данных?
• Вы хотите увидеть NetApp, Cisco UCS, Nexus... в действии уже сегодня, а не через месяц, когда поставят и установят демо-оборудование?
• У вас уже есть СХД, но вы хотите сравнить эффективность имеющейся у вас системы с NetApp?
• Вы планируете построить корпоративное облако?

Что внутри?

• NetApp V6240, 96 дисков*600Gb 10K RPM, 24 дисков*3Tb 7,2K RPM, 56 дисков FC,  26 дисков SSD, порты доступа: 8*FC 2/4/8Gb для подключения полок,  4*Ethernet 1GbE, 8 * Ethernet 10G. Модули для кэширования: FlashCache 1TB
• NetApp FAS3140, 28 дисков * 450Gb 15K RPM, порты доступа: FC 4/8Gb, Ethernet 1/10GbE
• NetApp FAS3020, 56 дисков * 146Gb 15K RPM, порты доступа: FC 2/4Gb, Ethernet 1GbE
• HP EVA 4400, 48 дисков * 1Tb 7.2K RPM, 24 диска * 400Gb 10K RPM, порты доступа: FC 4Gb

• HP DL585
• HP DL380
• HP DL360

• Extreme Summit x650, 24 * 10Gb/s Ethernet
• Brocade SilkWorm, 24 * 8Gb/s FC

Посетите Центр компетенции ИТ-ГРАД